【新サービス】AWS BatchがGA(一般利用開始)になったので使ってみた

#AWS Batch

#AWS

せーの

2017.01.06

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、せーのです。今日は本日よりGAになった新サービス「AWS Batch」を使ってみたいと思います。

AWS Batch

クラウド上で特定のバッチ処理を流したい場合、最初に考えるのはEC2を立ち上げてバッチを書いてcronあたりにセットする方法でしょう。もう少しAWSに詳しくなるとLambdaを使ってサーバレスにバッチを流すことを考えるかもしれません。ただLambdaでは処理時間5分を超えるような大規模なバッチは流せません。いくつかのバッチをフローとして次々流すのであればSWF(Amazon Simple Workflow)というサービスもあったりするのですが、こちらはとにかく仕組みを覚えるのが大変です（経験者談）。どのサービスも一長一短、ちょうどいい感じのものはないものか、という要望に答えるのがこの「AWS Batch」となります。

AWS BatchとはAWSフルマネージドなBatchサービスです。ユーザはバッチの処理内容を「ジョブ」として定義してあげるだけでAWSがそのボリューム、計算に必要なリソースの量、タイプ等をいい感じに用意してくれて流してくれます。バッチを流すのにバッチを流すサーバのことは一切気にしなくて良いわけですね。さらにこのサービス自体は無料で利用でき、かかるコストは実際にバッチを流すリソースとなるEC2の稼働料金のみになります。

用語解説

では具体的にAWS Batchを使う際の用語についてご紹介します。

ジョブ

実際に流すバッチ処理の中身になります。書き方は単純なシェルスクリプトの他にもLinuxで実行可能なファイルで書けます。またここで書いたバッチは実際にはEC2内にてコンテナとして動作するのでコンテナイメージをここに置いても動きます。

ジョブ定義

上のジョブをどのように実行するのかの定義情報です。IAM Roleを使って権限を定義し、使用するリソースのCPUやメモリの要件、コンテナのプロパティをここにまとめます。環境変数もここで定義できます。

ジョブキュー

ジョブを作成したらジョブキューに放り込みます。ジョブキューは後に紹介するコンピューティング環境にて実際にジョブが実行されるまでキューイング、待ち行列を作って待機します。ジョブキューには優先度を関連付けることができます。

スケジューラ

ジョブキューに接続されていて、キューに入っているジョブを順番にコンピューティング環境にて実行させます。基本はFIFO（先入れ先出し）になりますが、キューが共通のコンピューティング環境を共有する場合は優先度の低いキューより優先度の高いキューからジョブを優先して実行します。

コンピューティング環境

実際にジョブが実行されるリソース環境を指します。希望するインスタンスサイズを指定したり、使いたいvCPUの数を指定したり、という細かい設定ができます。またコストを考えてSpot Instanceを指定することもできます。ちょっとData Pipelineの設定に似てますね。 AWS BatchはこれらのリソースをAmazon ECSクラスタとして作成しますので、独自の環境が必要な場合はここでそのECSの中身となるインスタンスの設定を行うことになります。

つまりジョブとジョブ定義がワンセットとなってジョブキューに突っ込むことでスケジューラがいい感じに判断してあらかじめ希望していた条件のコンピューティング環境に随時流して実行してくれる、というのがAWS Batchの流れです。

大体のAWS Batchの流れがつかめたところで実際に触ってみましょう。

やってみた

ではとりあえず何か作ってみましょう。AWS Batchを開きます。

ジョブ定義を設定する画面が現れます。できればGAと共にここらへんが日本語化されてると敷居が下がっていいんですが。

最初に設定後ジョブをすぐ実行するかどうかを選び、前回作ったジョブがあるのであれば使うかどうか、ジョブ内でAWSリソースを使うことがあるのであればその権限のためのIAM Roleの選択、コンテナのイメージや中のコマンド、使いたいvCPU、メモリーの容量を指定します。今回はechoコマンドを投げる、という単純なものです。

ジョブ定義内で使いたい変数があればその定義とジョブ内で使いたい環境変数があればその定義をKey-Value形式で設定してNextを押します。ここらへんはプレビューを触ってみた虎塚の記事に詳しい解説が書いてあるのでそちらも参考になさって下さい。

次にコンピューティング環境とジョブキューの設定です。コンピューティング環境では「サービスロール」と「インスタンスロール」という２つのロールを設定します。サービスロールはAWS Batch自体が他のAWSリソースを操作するために必要な権限を、インスタンスロールはコンピューティング環境で動くECSが使う権限を設定します。どちらも「Create a new role」にしておくといい感じのIAM RoleをAWSが作ってくれるようなのでこのままにしておきます。既に必要なRoleを持っている方は選択しておいて下さい。

使うインスタンスの購入方法（オンデマンドかスポットインスタンスか)とインスタンスタイプ、最小、最大、起動時のvCPUの数を設定します。インスタンスタイプはoptimal(最適)がデフォルトで入っており、このままにしておくとAWSが最適なインスタンスタイプを選んでくれます。

ネットワーク構成を選びます。VPCと使用するサブネット、セキュリティグループを指定します。最後にジョブキューの名前を入力してそのジョブキューがどのコンピューティング環境で実行されるかを確認、既に入っているキューがあれば優先度を調整します。

これで設定は完了です。createボタンを押します。

少し待つとAWS Batchが作成されます。

最初にジョブキュー内でセットされた後に

RUNNABLE(動作可能)となります。リンクから中に入ってみると

ジョブが確認できます。上にステータスも順番に並んでいるのでどの順番で進んでいくのかもわかりやすいですね。RUNNABLEでコンピューティング環境の作成を待っていて、出来たらSTARTING、RUNNING、と進んでいって成功したらSUCCEEDEDになるんですね。コンピューティング環境ができるまで少し待ちます。

少し待つとSUCCEEDEDに移動します。まあechoなげているだけなので(笑)。ということで成功です！

ちなみにジョブキューやコンピューティング環境を削除する時はSTATUSをDISABLEDにすることが必要です。

ここから

こうですね。

まとめ

いかがでしたでしょうか。バッチ処理を考える時にそれを実行するサーバについては正直本論ではないのでいい感じにやってくれれば、と思うことも多いです。でも適当に環境を構築してしまうとCPUやメモリ不足でバッチ処理に時間がかかったり、最悪ハングアップしてしまったりすることもあり中々つらいところでしたが、AWS Batchを使えば実行環境の事は何も考えずにバッチの中身に集中できます。皆さんも是非試してみて下さい。